More and more, users of electronic devices are exchanging digital information asynchronously in substantially real time over the Internet using asynchronous communication protocols. Unlike traditional communication protocols, such as HyperText Transport Protocol (HTTP), the commands of an asynchronous protocol, such as publish/subscribe (pub/sub) communication protocols, are structured such that there need not be a one-to-one correspondence between requests and responses exchanged between the devices. In some cases a sender of information via the protocol need not wait, nor expect a response from, a receiver. Moreover, a receiver need not have sent a request corresponding to each received response. That is, a receiver may receive multiple responses to a single request and/or may receive an unsolicited message from a device. Thus, unlike HTTP where the reply is sent directly (synchronously) and only in response to the entity's request, the information can instead be sent in response to the sender's posting of the information (i.e., asynchronous to the request of information).
According to pub/sub communication protocols, an entity, referred to as a subscriber or subscriber client, is allowed to subscribe to information provided by another entity, referred to as a publisher, via a pub/sub service. Publishers publish to a distinct ID, typically a uniform resource identifier (URI) or uniform resource locator URL (URL), and subscribers subscribe by providing the ID. The publisher posts, i.e., publishes, the information to the pub/sub service identifying the tuple to be created or updated, the service then transmits the published tuple information to all interested parties, i.e., subscribers, via notification messages. The published information can be read simultaneously by any number of subscribers. So long as the subscriber remains subscribed to the information, the subscriber will continue to receive notification messages corresponding to the publisher's postings.
Notably, as is used herein, the term “publish/subscribe” refers to the class of services and associated protocols where a subscriber receives only the most recently published information in a notification message resulting from a subscription. That is, the pub/sub service transmits to the subscriber only the most current state of the published information, and does not queue, or store, previously published data for retrieval when the subscriber is offline or otherwise unsubscribed, such as with email and traditional message queues. Thus, unlike typical message queuing services, when a subscriber logs on or subscribes to the pub/sub service, the subscriber receives only the current state of the information, as well as subsequent updates to the information while the subscriber is subscribed. The subscriber does not receive previous updates that may have occurred while the subscriber was offline or unsubscribed. In addition, the pub/sub services as described herein are not topic based subscription services where typically any number of publishers may contribute to a single subscription. In topic based subscription services, whether a published entity is sent to a subscriber is based on its topic or categorization. Such topic based subscription services are also sometimes referred to as pub/sub services.
Typically, when the subscriber receives a notification message that includes the published information from the pub/sub service, the information is displayed to the subscriber in a certain manner or otherwise handled by a software client on the subscriber's device. Thus, while the information to be handled is dynamic, the manner in which the information is displayed or handled is generally pre-defined and static.
To address this shortcoming, one approach suggests creating a template in response to receiving a subscription request. Nevertheless, this approach merely creates a static template at the pub/sub service. This template cannot be updated dynamically and therefore suffers the same disadvantages. In another approach, processing policies for rendering and for making other data handling decisions are stored at the pub/sub service and implemented at the pub/sub service. Nevertheless, as before, the policies are static and cannot be dynamically fine tuned by a publisher or by a subscriber.
In another approach, rules and attributes associated with user-defined status levels are provided and stored in a single data tuple so that the notification message to the subscriber includes the rules and attributes as well as the user-defined status level. This approach can be extended to placing data handling information in the data tuple along with the published information so that the subscriber can receive both the data handling information and the published information. Nevertheless, this introduces many disadvantages. For instance, because the data handling information can be voluminous compared to just the updated data, the notification messages can be bulky and therefore consume resources. This can be especially problematic for handheld client devices that have limited bandwidth. Moreover, the one-to-one relationship between the data handling information and the data tuple is inefficient when the same data handling information can be used for many data tuples or when many different data handling information sets can be combined and used for one data tuple. In short, each of the approaches above fails to describe a flexible and dynamic way to provide data handling information for use by a pub/sub client to handle data published by the pub/sub service.